home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 1 (Walnut Creek)
/
Aminet - June 1993 [Walnut Creek].iso
/
usenet
/
sources
/
volume91
/
utilitys
/
memometr
/
part01
/
mm.doc
< prev
next >
Wrap
Text File
|
1991-06-18
|
21KB
|
340 lines
/*
* Information for MM Version 2.20, 19-May-1991
*
* MemMometer - A program hacked from Tom Rokicki's WFrags more or less...
* (in fact, a heck of a lot) in the style of Peter Da Silva's "Gauge."
* The program opens a narrow window with the same dimensions as the disk
* capacity gadget found in the top-level workbench window for an Amiga
* DOS v1.3 floppy volume. The sizing gadget is like the one in Gauge;
* to resize the window, just click the left mouse button over the "E".
* The "F" is the program title in this rather short manifestation of
* an Amiga Intuition window drag bar.
*
* My bin copy of Gauge broke when I put a Michigan Insider in my A1000.
* I did not have source for the Gauge program, so I conjured this one.
* To my chagrin, MM 1.0 broke when I got a 2000 (more on that shortly),
* the Amiga 3000 blew away the previous version of this program, too,
* of course. But that's the way it is with hardware-oriented software
* hacks! :-| Changes with this version involve reconstruction of the
* fast ram address menus to accomodate the A3000's 32-bit address space
* for fast ram at 7000000 to 7FFFFFF hex. Please note that Amiga DOS
* allocates this space in heap fashion (autoconfiguring memory in
* successively lower addresses starting from the top, while utilizing
* it within each zone in the usual fashion from the bottom up). The
* following table describes how to set MM for various Amiga 3000 memory
* configurations:
* Fast Ram Size Base Address
* 1 Meg 7f00000
* 2 Meg 7e00000
* 3 Meg 7d00000
* 4 Meg 7c00000
* 6 Meg 7a00000
* 8 Meg 7800000
* 10 Meg 7600000
* 12 Meg 7400000
* 14 Meg 7200000
* 16 Meg 7000000
*
* MemMometer may be started from an icon, a CLI, or the Run command
* from a CLI. MM uses dynamic allocation for its display data, and
* does its own resource tracking. MM will surrender any resources
* which it has successfully obtained from allocation requests if,
* while MM is running, requested resources are denied. This type
* of fault (exit code 20) proceeds silently, and without prior notice.
*
* Now for a run through MemMometer's menu mechanics. MemMometer opens
* with a non-interlaced-screen-height narrow window at the left side of
* the Workbench screen. The window width is the same as the width of the
* capacity gauge which Workbench used to render at the left side of the
* v1.3 top level window for a floppy volume. As with Peter Da Silva's
* original gauge program, the MemMometer has an E at the bottom of the
* window, and an F at the top.
*
* The E and the F are respectively, the window sizing gadget, and the
* window titlebar. While MemMometer can and does automatically arrange
* the window to suit the memory configuration, it depends on the user to
* select appropriate memory size and address values via the menus. The
* menu style is the usual Amiga Intuition menu set; selection is achieved
* by clicking the left mouse button while the mouse pointer is anywhere
* within the program's window boundary, and then activating the menu bar
* by holding down the right mouse button and sliding the mouse pointer
* along the Workbench screen title bar at the top of the Workbench screen.
*
* At the left side of the Workbench screen title is the Project Menu. The
* Project Menu has three options. The first option is "Front", which is a
* window-to-front command for the event that the MM window was partially
* buried by the opening of new windows after MM was invoked. If the
* right mouse button is released while the mouse pointer is directly over
* the Front menu item, the MM window will oblige by popping forward to an
* unobstructed view. The second menu option is the "Back" item, which
* will move the MM window back behind any other windows that have been
* opened on the Workbench screen (with exception of a backdrop window).
* The third Project menu option is the "Quit" option, which directs MM to
* close its window and release the AmigaDOS resources it has allocated.
* The normal return code is zero.
*
* The second Intuition menu is the Setup menu. There are two Setup menu
* items. The first item is the "Mode" item. MM has two modes, and they
* are selected by sliding the mouse pointer straight down from the screen
* title bar over the Mode item , and then moving the pointer to the right
* as the mode submenu is activated. The activated submenu provides two
* choices, "Frags" and "Warps". Frags are rather much the same as they
* were in Da Silva's gauge program. "Frags" is the default menu selection
* with which MM is first initialized. The Frags display is described in
* the following table:
*
* 2-Color Workbench 4-Color Workbench 8-Color Workbench
* Unallocated Blue Black Black
* Allocated White Orange Yellow
* Fragmented Blue Blue Blue
*
* Unallocated memory is free memory available to programs. The programs
* may obtain this memory from AmigaDOS through allocation requests. The
* Allocated memory is memory assigned to programs running under AmigaDOS.
* Fragmented memory consists of interleaved small memhunks, some of which
* are assigned to programs and some of which are in the free memory pool.
* The smallest fragments are 8 bytes, and the largest memhunks may be more
* than a megabyte. The fragmented class is assigned when, in making the
* MM window display, a single horizontal pixel line was found to represent
* both allocated and unallocated memhunks. For this reason, for a full
* window height MemMometer, the resolution of the fragmentation is shown
* in more detail on interlaced Amiga Workbench screens.
*
* The second mode item selection is the "Warps" mode. While the Frags
* mode is usually utilized as a low-priority background indicator, the
* Warps mode is usually utilized at a somewhat higher priority for the
* purpose of tracking bugs and system irregularities. In this context,
* I define warps as a form of discretized sample-to-sample differencing
* function for some arbitrary segment of memory. Warps are determined by
* dividing the selected address space evenly among the MemMometer display
* pixels, computing an assignment checkfunction for each pixel line of the
* display on the associated assigned memory space at some sample time, and
* then, while retaining the previous pixel-by-pixel record, repeating the
* same evaluation the second sample time and comparing the sequentially
* determined checksums. A "checksum" is computed by means of a sequential
* bit-wise eXclusive OR assignment. This type of checksum can readily
* detect zeroed or changed values. In the table below, logical FALSE is
* zero, logical TRUE is taken as 0xffffffff and VALUE is anything else.
* Colors indicate the type of change. Colors for the most part follow
* the v1.3 standard CBM workbench color set; they're shown as follows:
*
* Pen # Color Pen # Color
* 0 Blue 4 Green
* 1 White 5 Red
* 2 Black 6 Cyan
* 3 Orange 7 Yellow
*
* These colors are used to map the changes in memory content from sample
* to sample as programs multitask together:
*
* Condition 2-Color Workbench 4-Color Workbench 8-Color Workbench
*
* VALUE ===> VALUE Blue Blue Blue
* VALUE =/=> VALUE White Orange Orange
* FALSE ===> FALSE Blue Black Black
* FALSE ---> VALUE White Orange Yellow
* VALUE ---> FALSE White White Red
* TRUE ---> FALSE Blue Black Cyan
* TRUE ---> VALUE Blue Black Cyan
* TRUE ===> TRUE Blue Blue Green
* FALSE ---> TRUE Blue Blue Green
* VALUE ---> TRUE Blue Blue Green
*
* The second Setup menu item is a Frequency selection submenu. While the
* selected value does set a minimum frequency with which the memory state
* will be examined, it's done by introducing a delay between measurements.
* The introduced delay will be equal in seconds to the value selected in
* the submenu. The delay is accomplished by the AmigaDOS timer.device
* using the VBLANK mode. It was not thought worth the difficulty to make
* the timing as precise as would be possible using the cia.resource, as
* that might make the resource less useful to other programs, and as well
* would mean extra effort adjusting for memory size-dependent scan times
* from the various memory sizes selectable with the MM program. Delay
* intervals of 1, 2, 5, and 10 seconds are available.
*
* The third Intuition menu is a Priority menu. This menu applies only to
* the MemMometer program and its associated CLI process. Initially it is
* at priority 0 with the expectation that the user will set it lower once
* the program is running, in order to give more time to the other active
* processes the user will be running. A value of -50 is recommended. In
* the event the Priority of MM is changed via the menu, the CLI inherits
* MemMometer's new priority and retains that priority even after MM quits.
* Thus, with extreme priority settings, it may be better to "Run MM" to
* keep from passing the extreme priority to subsequent processes spawned
* from the CLI that was used to invoke MemMometer. Also, go easy with the
* positive priorities; remember that with AmigaDOS version 2.0 the DOS
* input.device runs priority 20, the SCSI bus handler is 12, SCSI.device
* is 11, FileSystem is priority 10, and the CON: and trackdisk.device
* are priority 5 usually. Note that the first three MemMometer menu
* items are used to increment or decrement a priority selected in the
* lower part of the menu. Selection of the "NORM" menu item removes any
* increment or decrement previously set while at any given level.
*
* The remaining Intuition menu selections are provided so that the range
* and base address of the memory examined may be adjusted for the user's
* Amiga memory configuration. Note that the base address must always be
* set to the correct base address for the given memory configuration in
* order for the Frags option to work properly, but that the range may be
* adjusted to give a better resolution for the first segments around the
* base address, if desired. Menus are provided for Chip memory, the old
* Slow-Fast (C00000/Ranger) memory, and Fast memory. While I have had no
* difficulty as a result of selecting a range of memory that involved a
* non-existent seqment for Chip or Fast memory in either Frags or Warps
* mode, when I selected non-existent SFMemory on my Fat Agnus Amiga 2000
* in Warps mode, it resulted in a total system-wide red Guru 4 (illegal
* instruction exception).
*
* After that, I decided to post a requester for the user to issue terse
* warning that a crash is _possible_ with incorrectly specified menu
* selections in warps mode. Since it is possible, for example, to roll
* over on 24-bit addresses via large memory size menu selections, one
* can access forbidden zones through inappropriate settings of the Fast
* Mem menus as well. Thus MM also calls the requester if the Fast Mem
* size menu is changed. The requester displays the message:
*
* WARNING! CRASH POSSIBLE
* MENU MEMORY SELECTIONS MUST
* REFERENCE EXISTING MEMORY
*
* Risk It Retreat
*
* You don't have to worry about a crash if you really have an amount of
* SF or Fast memory equal or greater than the amount you specified and
* the base address is within what you specified (the default base address
* for SF Mem is C00000 and 200000 for A2000 Fast Mem). Too bad I have to
* do this, but it is a matter the hardware regards seriously, as some
* registers do things when they are read, never mind what they do when
* they are written! If you really want to be annoyed, just get Bryce
* Nesbitt's Enforcer program. It will yap at you through the serial port
* every time any program (such as this one) reads the zero page...
*
* So, here you see the two options. The left button says - Risk It -.
* That's a comfortable gamble if you know your Fast memory configuration.
* Pre Fat-Agnus Amiga 2000 machines have 512K of Slow-Fast memory. The
* Newer 2000s have no C00000 Slow Fast memory, and the A3000 only has the
* 200000 ZorroII 16-bit Fast Memory if you added a Mem card - so beware
* of this and try the other settings when you have nothing else going on,
* until you gain a knowledge of what is safe. The - Retreat - option sets
* the SF or Fast Memory Size selected internal to the MemMometer program
* to zero and clears the display. (It does leave the menu items checked,
* though, so you will have to remember to re-select suitable menu values
* in order to get the display to show something in each existing memory
* type. For Chip and Fast memory this will simply entail going back into
* the menu and again selecting whatever was previously checked. The SF
* memory size should be set either to appropriate values or to "NONE".)
*
* Note that in the display there may at any time be anywhere from one
* to three MemMometers - for Chip (left-hand column), another for the
* Slow Fast mem (center column) and yet another for Fast mem (right-hand
* column). These MemMometers can be turned on or off as desired by
* selecting "NONE" or the various items in the Size menus.
*
* Parts of several freely distributable programs have been used to make
* MemMometer. Menus, for instance, are done in the style VT100 (Wecker,
* et al). As with the VT100 program, MemMometer has preset variables.
* However, the program does not yet contain a script file reader or an
* AREXX interface with which to automatically set the variables. Likely
* it is that I'll write the code for that some time this century!
*
* MemMometer uses forbid() and permit() when it examines the mem list in
* Frags mode. I suppose it is possible with large amounts of memory to
* scan, that some gross treachery can happen while the list is locked.
* However, with my 4 meg Amiga 3000 I've not seen it. It takes a while
* after startup to settle out and display the large byte counts associated
* with Fast mem, so be patient... MemMometer is most useful for finding
* out why large programs won't load. It's also useful in development for
* seeing the impact your application is having on memory fragmentation,
* or how various programs (and viruses, for that matter) are allocating
* memory.
*
* The Warps mode displays any change it sees in memory from one sample
* to the next; BUT this mode only works sensibly when JUST ONE memory size
* selection is active (set others to "NONE"). The memory space is scanned
* asynchronously, so it can have sample alias difficulties. However, the
* Warps mode does not use forbid(), permit(), enable(), disable(), or any
* other constrictive system call. It just does a lot of read-only memory
* cycles and writes the result in its own dynamically allocated memory
* space.
*
* To run MemMometer, simply type
*
* run MM
*
* or click on the icon.
*
* Then open the menu item selections and set them for your configuration.
* Frags mode, and 512K of CHIP @0 is the default these days, what with
* hugh variety of configurations routinely encountered. The modes are
* are color coded into the "F" and "E" indicators in accordance with the
* AmigaDOS v1.3 color table; AmigaDOS v2.0 looks pale by comparison:
*
* Mode Indicator 2 color WB 4 Color WB 8 Color WB
*
* Frags E Blue Blue Blue
* Warps E White Orange Yellow
*
* One column:
* Chip F Blue Blue Blue
* Slow-Fast F Blue Black Cyan
* Fast F White Orange Yellow
*
* Two columns:
* Chip +SF F Blue Blue Blue
* Chip +Fast F Blue Black Cyan
* SF + Fast F White Orange Yellow
*
* Three columns:
* C + SF + Fast F Blue Blue Blue
* None F White Orange Orange
*
* The source code included with this distribution was compiled with the
* Manx Aztec C compiler, version 3.6a in 16-bit integer mode. Numerous
* type casts in the code, as well as other non-alignments with the Lattice
* environment would make compilation under versions of Lattice difficult.
* Sorry. Compilation instructions are of course in the makefile included
* in the distribution.
*
* About my part of C code - it wasn't done for speed, as I am sure you can
* tell. If I wanted speed I would have used assembly language. It also
* likely isn't elegant code, by a long shot (unless it's the part I got
* from Rokicki's WFrags). But assembly language is time-consuming to
* write, so that won't happen any time soon. Maybe the next thing will be
* the AREXX port - so that other programs can specify a low address and a
* byte count range for one of the MemMometers to display (say, within the
* specified menu selection span). Gross comments about the code or bug
* reports may be e-mailed to me at the site domain specified below.
*
* About everyone else's C code in MM - Let's see, VT100 (Wecker et al) has
* been freely distributable since the early days of the Amiga. When VT100
* was first posted, Wecker did not prepend a copyright to the code. He
* later discovered that his employer (DEC) routinely required employees to
* sign a contract statement which granted to DEC all rights with respect
* to codes written by DEC employees, whether the codes were written on the
* company's time/facilities or otherwise. I do not know how the matter
* was resolved, but VT100 still seems to be on the freely distributable
* software list. The menus in MM, while styled with the same code forms
* as were used with VT100 v2.3, are of course different in content in any
* case. The WFrags program was, I believe, a version by Tom Rokicki (the
* Amiga Tex guy) might be evolved from the Frags program originally put
* to the net by Mike Meyer. WFrags was submitted to the net without a
* prepended copyright notice, evidently intended as freely distributable
* software.
*
* The spirit of these contributions is that they are not to be used for
* commercial purposes, and the original authors certainly appreciate
* being cited for their work. So I just did that. The timer codes are
* exerpted from a network article by Andy Finkel of CBM, submitted as a
* demonstration of the ease of implementing the Amiga timer.device in C.
*
* So, for my part, I add no further restrictions to the codes in MM.
* In that spirit, I hereby submit the following Standard Disclaimer:
*
* The authors accept no responsibility for anything either beneficial or
* detrimental that may happen as a result of using the codes in MM. The
* codes are intended for non-commercial use only.
*
*
* Howard Hull hull@ncar.edu
*
*/